Remarks 

In the Office Action mailed February 13, 2007: 

1 . Claims 1-12 and 25-28 were rejected under 35 U.S.C. § 1 12, ^ 2 as being 
indefinite; and 

2. Claims 1-43 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent No. 5,903,878 (Talati). 

I Rejections under 35 U.S.C. S 112, 2 

Claims 1-12 and 25-28 were rejected under 35 U.S.C. § 1 12, f 2 on the basis that they 
include both product and process. 

Claims 1, 25, 27 and 29 were amended to clarify the roles of the products recited in the 

claims. 

II Talati (U.S. Patent No. 5.903.878^1 

Talati is directed to a Method and Apparatus for Electronic Commerce (title), and 
provides a system that includes an originator, a recipient and a transaction administrator (TA). 
The originator (e.g., a client or purchaser) originates an electronic commerce transaction (column 
2, lines 55-60). The recipient (e.g., a merchant or vendor) receives payment for the transaction 
(column 2, lines 60-65). The TA (e.g., a credit card authority or financial network) authenticates 
the originator and recipient and validates transaction contents (column 2, line 65 - column 3, line 
3). 

In Talati, an originator initiates a purchase or payment by sending a transaction to the 
recipient. The transaction includes some details of the purchase, along with a unique transaction 
identifier (UTID) generated by the originator. After receiving the transaction, the recipient sends 
to the TA a payment authorization request that includes the UTID. Upon receipt of the payment 
authorization request, the TA validates the originator and the recipient. Validation of the 
originator requires the TA to send to the originator a validation request that includes the UTID. 
The originator extracts the UTID and compares it to a list of generated transaction identifiers to 
determine if the transaction was initiated by the originator, (column 3, lines 4-48) 

In a claimed embodiment of Applicants 5 invention, a system (e.g., a verification system) 
for verifying a customer's financial instrument (e.g., credit card, bank account) initiates one or 
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more transactions using that instrument. The transactions are not initiated by the customer. The 
system stores details of the transactions and later receives those same details from the customer 
to verify that the customer controls the instrument. The system compares the details offered by 
the customer to the stored details. If they match, the customer is then allowed to use the 
instrument to perform financial transactions. Methods claimed for verifying a financial 
instrument in the present application do not recite actions that must be performed by entities 
outside the verification system. 

Talati cannot anticipate Applicants 5 invention, for reasons including the following. 

A. Talati Does Not "Store One or More Attributes" of one or more Transactions 
or "Receive a Set of Proffered Attributes" of the Transactions 

In claimed embodiments of the present invention (e.g., claim 1), a system for verifying a 
customer's authority to use a financial instrument initiates one or more transactions involving the 
instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer for comparison with the stored attributes. 

The stored attributes are specifically defined as "attributes of said one or more 
transactions" (see claim 1), and include transaction details such as number of transactions 
performed, the amount of a transaction, the type of transaction (e.g., credit, debit, deposit, 
withdrawal) and the merchant name or account used by the system for the transaction (page 2, 
lines 13-15 of the application; claims 4-7; claims 20-24). Thus, the attributes may comprise 
details of payments involving the financial instrument. 

Talati does not store transaction "attributes" or receive a set of proffered attributes of a 
transaction, as recognized by the Examiner (page 4 of the office action). However, the Examiner 
compared Applicants' transaction attributes to information such as a mother's maiden name, 
social security number or driver's license number (column 5, lines 33-40; column 6, lines 25-32) 
in an attempt to show that Talati "receives a set of proffered attributes." 

But this comparison must fail, because none of this information is part of a transaction 
involving an originator's financial instrument . In Talati, this information is used solely for the 
purpose o f validating an originator's identity , does not reflect any details of a transaction, and 
therefore cannot be equated with "one or more attributes of said one or more transactions." 



H:\PayPaI\PAY00-003\Reply (March 2007).doc 



09/901,954 



11 



B. Talati Does Not Accept Use of a Financial Instrument for a Subsequent 
Transaction after Matching Proffered Attributes with Stored Attributes 

In claimed embodiments of the present invention, a system for verifying a customer's 
authority to use a financial instrument initiates one or more transactions involving the 
instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer for comparison with the stored attributes. If the comparison succeeds, the 
customer is permitted to use the financial instrument in a subsequent transaction. 

In particular, one or more claims of the present application recite "accepting use of the 
financial instrument by the customer for a subsequent transaction if said proffered attributes 
match said stored attributes" (e.g., claim 1) or similar language. Thus, the proffered and stored 
attributes of one or more previous and completed transactions must match in order for a 
subsequent customer transaction using the financial instrument to be permitted. 

The Examiner's rejection of this element cites column 6, lines 33-36 of Talati, and must 
fail for at least two reasons: 

(1) The transaction approved in Talati is the same transaction that was validated and 
for which an originator's identity was verfied, and thus is not a subsequent transaction. As 
described above in Section II. A, Talati does not store or receive attributes of one or more 
transactions. Instead, for each transaction from an originator, Talati verifies the originator's 
identity using personal data of the originator (e.g., driver's license number, SSN). If his/her 
identity is verified and the originator validates the transaction, the current transaction is allowed 
to proceed (see column 3, lines 3-6). Specifically, "[u]pon receipt of validation or non- validation 
from the originator, the TA confirms or aborts the transaction ..." (column 3, lines 49-50, 
emphasis added). 

(2) Approval of a transaction in Talati does not depend upon a comparison of stored 
and proffered attributes. Instead, as the cited section of Talati states, the current transaction is 
allowed to proceed "if there is a confirmation by client 10 of transaction validity" (column 6, 
lines 35-36). Talati's confirmation of transaction validity is not the same as the comparison of 
information proffered by the originator (e.g., mother's maiden name, SSN, driver's license 
number). Transaction validity refers to the originator's comparison of a UTID received from the 
CA with the originator's list of UTIDs (column 6, lines 12-19). Therefore, Talati cannot and 
does not "accept[ ] use of the financial instrument by the customer for a subsequent transaction if 
said proffered attributes match said stored attributes" as recited in claim 1. 
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In summary, Talati: 

— authorizes use of a financial instrument for a current transaction, not a subsequent one; 

and 

— bases authorization of the current transaction on the originator's validation of the 
transaction's UTID, not a comparison of a set of stored attributes of a previous transaction 
against a set of attributes proffered by the originator. 

C. Talati Does Not Select Values for a Series of Transactions 

In a claimed embodiment of the present invention, a system for verifying a customer's 
authority to use a financial account selects values for a series of transactions involving the 
account, initiates the transactions, stores a set of details of the transactions, then receives a set of 
test details from the customer for comparison with the stored details. If the comparison 
succeeds, the customer is permitted to use the financial account in a subsequent transaction. 

Talati does not select values for transactions. This element of the claims (e.g., claim 13) 
was rejected without citation to any part of Talati (page 6 of the office action). Nor could any 
part of Talati be relied upon for this subject matter. 

In particular, in Talati a transaction is initiated by an originator (column 2, lines 55-56), 
and it is the originator who specifies a value for the transaction (column 2, lines 55-59). The 
same entity that selects values (in claim 13) also initiates the transactions, stores details, receives 
test details, compares the stored and test details and authorizes use of the financial account in a 
subsequent transaction. The originator cannot be considered part of Talati' s system and the 
Talati system therefore has no control over the values of transactions. 

D. No Entity in Talati Can Perform Applicant's Method 

Performing a method described in Talati requires multiple independent entities to execute 
different operations. In particular, the originator originates an electronic commerce transaction 
and later approves or disapproves the TA's validation request. The recipient receives the 
transaction and issues a payment authorization request to the TA. The TA receives the payment 
authorization request, validates the UTID and confirms or aborts the transaction depending on 
whether the originator approves the validation request. Each of these entities (originator, 
recipient and transaction administrator) operates autonomously of each other and is incapable of 
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performing the functions of any other entity. 

The entities must operate independently of each other in order to allow the originator and 
the recipient to trust that the other will perform its obligation. Thus, no one entity in Talati is 
capable of performing all elements of a claimed embodiment of Applicants' invention. For 
example, an originator may initiate a transaction using a financial instrument, but the originator 
cannot then later accept use of that financial instrument as recited in claim 1 . Use of the 
financial instrument may be accepted by the recipient in Talati, as another example, but the 
recipient does not initiate a transaction or compare stored details of the transaction to details 
offered by the originator. 

Ill Selected Claims 

To the extent that arguments from Applicant's Appeal Brief (filed May 11, 2006) are not 
specifically recited in this Reply, such arguments should be deemed incorporated herein and in 
no way abandoned. 

A. Claims 1-12, 29, 42-43 

(1) Claims 1 and 29 recite initiating one or more transactions using a financial 
instrument identified by a customer, storing attributes of the transactions, receiving proffered 
attributes, comparing the proffered attributes to the stored attributes, and accepting the financial 
instrument for a subsequent transaction if the compared attributes match. 

a) The Examiner recognizes that Talati does not teach the "initiating" or 
"storing" elements of claims 1 and 29 (page 4 of the office action), but opines that these 
features are well known. 

Applicants traverse. If these features were well known at the time of Applicants' 
invention, a corresponding prior art reference should be identified that describes a system 
configured to perform the method recited in claim 1 . 

In particular, even if a "conventional credit card system maintains transaction 
history includes one or more previous transactions conducted by a cardholder" (office 
action, page 4, lines 9-11; emphasis added), those transactions, as indicated, are initiated 
by cardholders , not the credit card system . And, a conventional credit card system does 
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not receive from a cardholder attributes of those transactions, or condition use of a credit 
card in a later transaction on the cardholder's submission of matching attributes. 

b) Also, as discussed above in Sections II.A and II.B, Talati does not 
"receiv[e] a set of proffered attributes" of the one or more transactions or "accept[ ] use 
of the financial instrument by the customer for a subsequent transaction if said proffered 
attributes match said stored attributes 55 (emphasis added). 

c) Further, the method of claims 1 and 29 is performed entirely within a 
single system. Talati clearly requires at least three separate and independent entities - an 
originator, a recipient and a transaction administrator (Fig. 1; Fig. 3; Abstract; column 3, 
lines 51-55). Thus, there is no "system" in Talati that can perform the recited method. 

(2) Claim 8 recites the operation of a transaction processor to electronically initiate 
the one or more transactions. As specified in claim 1, the transaction processor is part of the 
system that performs the method of verifying a customer's authority to use a financial 
instrument. 

The Examiner rejected claim 8 by comparing Applicants' transaction processor with the 
originator's processor in Talati. This comparison fails because the originator and the originator's 
processor are wholly independent from Talati' s transaction authority (TA) or credit authority 
(CA), as shown in FIG. 3 and described at column 4, lines 58-65. Indeed, the Talati system 
would be useless if the originator was not separate and distinct from the other entities (i.e., the 
recipient and the TA/CA). 

B. Claims 13-24 

Claim 13 recites selecting values for a series of transactions using a financial account 
identified by a user, initiating the transactions, storing details of the transactions, receiving a test 
set of details of the transactions, comparing the test set of details to the stored details, and 
accepting the financial account for a subsequent transaction if the compared details match. 

As described above in Section II.C, Talati does not teach or suggest "selecting values for 
a series of transactions involving the financial account." Claim 13 was rejected "by the same 
rationale" as claim 1 (page 6 of the office action), without addressing this claim element, even 
though this element is not found in claim 1 . Therefore, claims 13-24 should be allowed. 
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Also, as discussed above in Sections II.A and II.B, Talati does not receive a test set of 
details of the series of transactions or authorize the user to conduct a subsequent transaction if 
the test set of details matches stored details of the transactions. 

Further, as described in Section III.A, the knowledge of one skilled in the art at the time 
of Applicants' invention cannot be relied upon to make obvious the subject matter not found in 
Talati. Even if some of the subject matter was known, there was no reason to use that knowledge 
or combine it with other knowledge in a way that makes the Applicants' invention obvious. For 
example, a credit card system would never be configured to perform a claimed method of the 
present application because the credit card system already knows that the cardholders for which 
it retains transactions attributes has authority to use their credit cards. 

C. Claims 25-26 

Claim 25 recites " after the one or more transactions are completed , receiving from the 
user a second set of details" (emphasis added). Claim 25 was rejected "by the same rationale" as 
claim 1, despite the fact that this limitation is not found in claim 1. Indeed, as described above in 
Section II, Talati authorizes only one transaction at a time, and the information the Examiner 
equated with Applicants' "details" must be received before or during the current transaction, not 
after. In particular, in Talati an originator must receive and validate a transaction before it can be 
completed. 

Also, as discussed above in Sections II.A and II.B, Talati does not receive a set of details 
of a previous transaction or authorize the user to conduct a subsequent transaction if the supplied 
set of details matches stored details of the transaction. 

Further, as described in Section III.A, the knowledge of one skilled in the art at the time 
of Applicants' invention cannot be relied upon to make obvious the subject matter not found in 
Talati. Even if some of the subject matter was known, there was no reason to use that knowledge 
or combine it with other knowledge in a way that makes the Applicants' invention obvious. For 
example, a credit card system would never be configured to perform a claimed method of the 
present application because the credit card system already knows that the cardholders for which 
it retains transactions attributes has authority to use their credit cards. 

Yet further, the method of claim 25 is performed entirely within a single system. Talati 
clearly requires at least three separate and independent entities - an originator, a recipient and a 
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transaction administrator (Fig. 1; Fig. 3; Abstract; column 3, lines 51-55). Thus, there is no 
"system" in Talati that can perform the recited method. 

D. Claims 27-28 

Claim 27 recites " after the one or more transactions are completed , receiving from the 
user a second set of details" (emphasis added). Claim 27 was rejected "by the same rationale" as 
claim 1, despite the fact that this limitation is not found in claim 1. Indeed, as described above in 
Section II, Talati authorizes only one transaction at a time, and the information the Examiner 
equated with Applicants' "details" must be received before or during the current transaction, not 
after . In particular, in Talati an originator must receive and validate a transaction before it can be 
completed. 

Also, as discussed above in Sections II. A and II.B, Talati does not receive a set of details 
of a previous transaction or authorize the user to conduct a subsequent transaction if the supplied 
set of details matches stored details of the transaction. 

Further, as described in Section III.A, the knowledge of one skilled in the art at the time 
of Applicants' invention cannot be relied upon to make obvious the subject matter not found in 
Talati. Even if some of the subject matter was known, there was no reason to use that knowledge 
or combine it with other knowledge in a way that makes the Applicants' invention obvious. For 
example, a credit card system would never be configured to perform a claimed method of the 
present application because the credit card system already knows that the cardholders for which 
it retains transactions attributes has authority to use their credit cards. 

Yet further, the method of claim 27 is performed entirely within a single system. Talati 
clearly requires at least three separate and independent entities - an originator, a recipient and a 
transaction administrator (Fig. 1; Fig. 3; Abstract; column 3, lines 51-55). Thus, there is no 
"system" in Talati that can perform the recited method. 

D. Claims 30-38 

Claim 30 specifies that a test set of details of one or more transactions is received 
independently of any transaction, and that the test set of details is compared to a stored set of 
details after the one or more transactions have been completed. 
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The Examiner recognized that Talati does not receive transaction details independent of 
any transaction (page 7 of the office action). And, as described above in Section II, Talati fails 
to teach one to compare test details to stored details to determine whether to authorize a 
subsequent transaction. And, as described above in Section III. A, Applicants assert that these 
features were not well known in the art. 

In particular, even if a conventional credit card system maintains a transaction history of 
a cardholders' transactions, that system does not receive details of the transactions after the 
transaction s have completed . Instead, as with Talati, a credit card system requires receipt of a 
transaction's details before it will approve or complete the transaction. And, a credit card system 
need not and does not compare stored details of a transaction with details offered by a 
cardholder, especially details offered independent of any transaction. 

E. Claims 39-41 

Claim 39 specifies that a confirmation set of details of one or more transactions is 
received independently of any transaction, and that the confirmation set of details is compared to 
a stored set of details after the one or more transactions have been completed. 

Claim 39 was rejected "by the same rationale" as claim 30. But as described above (in 
Section III.D), the rejection of claim 39 is deficient. The rejection of claim 39 is therefore 
deficient in the same ways. 

As described above in Section III. A and III.D, Applicants assert that features of claim 39 
recognized by the Examiner as not being taught by Talati were not well known in the art. In 
particular, even if a conventional credit card system maintains a transaction history of a 
cardholders' transactions, that system does not receive details of the transactions after the 
transactions have completed . Instead, as with Talati a credit card system requires receipt of a 
transaction's details before it will approve or complete the transaction. And, a credit card system 
need not and does not compare stored details of a transaction with details offered by a 
cardholder. 

CONCLUSION 

No new matter has been added with the preceding amendments. It is submitted that the 
application is in suitable condition for allowance. Such action is respectfully requested. If 
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prosecution of this application may be facilitated through a telephone interview, the Examiner is 
invited to contact Applicant's attorney identified below. 



Park, Vaughan & Fleming LLP 

2820 Fifth Street 
Davis, CA 95618 
(530) 759-1660: voice 
(530) 759-1665: facsimile 



Respectfully submitted, 



Date: March 27. 2007 



By: 
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